What's in a (Pattern) Name?
The Importance of Good Names
Names are important because they are a key part of how we communicate. Names are labels we attach to concepts. Good names help us communicate the concepts. This is true both for when communicating with people who already know the names and especially for those who don't. Let me illustrate this with an example.
Early in my pattern-writing days, I attended the very first Pattern Languages of Programs (PLoP) conference. (http://www.hillside.net/conferences/plop)Well known author Jim Coplien (referred to as "Cope" by all his friends) had a pattern language of organizational patterns being workshopped. One of the patterns was called "Buffalo Mountain" and another was called "Architect Also Implements". These two pattern names are at opposite ends of the spectrum as far as pattern names are concerned.
The gist of "Architect Also Implements" can be gleaned from the pattern name by even those who have not read the pattern. The name is both a placeholder for the pattern and meaningful in its own rite.
"Buffalo Mountain" on the other hand is not very communicative. To this day I can still remember the story behind the name but I cannot remember what the pattern is actually about. The name was based on a graph that plotted some data related to the pattern. An early reviewer thought it resembled the profile of a nearby mountain called "Buffalo Mountain". So while the pattern name is memorable, it is not very evocative.
Closer to home, Self Shunt (see Hard-Coded Test Double on page X) is an example of a name that is less than evocative. Michael Feathers does a good job explaining the background of the name in his description of the pattern but unless you've read that description, the name is "just a name". A more evocative name might be something like "Testcase Class as Test Double".
Other Naming Considerations
People might ask why I propose alternate names for some patterns. The reasons stated above are just one of the reasons. Another reason is that in a larger collection of patterns (such as this book), it is important for there to be a "system of names".
Let me illustrate this with an example. Many people advocate the use of a setUp method to set up the test fixture. This moves the fixture setup logic out of each individual Test Method (page X) into a single place where it can be reused. Many people might refer to this pattern as "Shared Setup Method". But in this pattern language, I've chosen to call it Implicit Setup (page X). Why?
It comes down to the names of other patterns in the language. On the one hand, there is Shared Fixture (page X) which "Shared Setup Method" could easily be confused with. (The latter is about sharing code while the former is about sharing the runtime objects in the fixture.) And on the other hand, the two major alternatives to Implicit Setup are called Inline Setup (page X) and Delegated Setup (page X). Wouldn't you agree that "Inline, Delegated, Implicit Setup" forms a better "system of names" than "Inline, Delegated Setup" and "Shared Setup Method"? The connection between the pattern names is much more obvious when we consider all the major alternative patterns when choosing the system of names.
Why Standarize Testing Patterns?
The last part of this soapbox is about why I think it is important for us to standardize on the names of the test automation patterns and especially those related to Test Stubs (page X) and Mock Objects (page X). It relates to succinctness of communication. When someone tells you to "Put a Mock in it" (pun intended!), what advice are they giving you? Depending on what they mean by a "Mock", they could be suggesting that you control the indirect inputs of your system under test (SUT) using a Test Stub, replace your database with a Fake Database (see Fake Object on page X) that will reduce test interactions and speed up your tests by a factor of fifty (yes 50! See the sidebar Faster Tests Without Shared Fixtures (page X)) or maybe they are suggesting that you verify that your SUT is calling the correct methods by installing a Eager Mock Object (see Mock Object) preconfigured with the Expected Behavior (see Behavior Verification on page X)? If everyone used "Mock" to mean a Mock Object and no more or less, the advice would be pretty clear. As I write this, the advice is very murky because we have taken to calling just about any Test Double (page X) a "Mock Object" (despite the objections of the authors of the original paper on Mock Objects. [ET])
Further Reading
If you want to find out what "Buffalo Mountain" is really about, go to http://www1.bell-labs.com/user/cope/Patterns/Process/section29.html.
You can find "Architect Also Implements" at http://www1.bell-labs.com/user/cope/Patterns/Process/section16.html.
Interestingly, Alistair Cockburn wrote a similar comparison of pattern names in an article on his website (http://alistair.cockburn.us/crystal/articles/wdictp/whatdoicallthispattern.html) and chose exactly the same two pattern names in his comparison. Coincidence or pattern?
Copyright © 2003-2008 Gerard Meszaros all rights reserved